4. How Did People Write Code in the Early Days of Computing?
From rewiring to stored programs
When computers were first built, how did people program them? Early computers had nothing like today's software. More like desk calculators, they used switches such as relays and vacuum tubes to form logic circuits and were designed for a single purpose.
"That one breaks German military codes."
"This one does arithmetic."
"Could I build one for ballistic calculations?"
"How many relays and vacuum tubes would it need?"
ENIAC could run different programs by changing its plugboard wiring and switch settings. This was a cumbersome process, and changing a program could take days. Punched cards were used for input and output, not to store its programs[1][4].
Programming became much more practical when stored-program computers were introduced. A program could be loaded into electronic memory and executed without rewiring the machine. The Manchester Baby ran a stored program in 1948, and EDSAC entered regular operation in 1949. EDVAC was highly influential in the development of the stored-program design, although it became operational later.
From machine code to assembly language
A program is made up of instructions that a machine can understand and execute. At the lowest level, these instructions are called machine code. On binary computers such as EDSAC, machine code is encoded as patterns of binary digits, or zeros and ones, which are difficult for people to read and remember.
That is why early forms of assembly language appeared near the beginning of computer programming. Instead of numeric machine instructions, they used short symbols called mnemonics to make instructions easier to express. EDSAC programmers used single-letter order codes. A small bootstrap program called the Initial Orders read these codes from paper tape, translated them into machine instructions, and loaded them into memory[2].
Each EDSAC instruction occupied one 17-bit word:
- The first five bits were the operation code.
- The next bit was unused.
- The next ten bits were the operand, representing an address.
- The final bit selected either a short or long operand.
The two EDSAC assembly instructions shown above can be explained as follows:
T 0 S: Store the upper 17 bits of the value in the accumulator at memory address0, then clear the accumulator by resetting it to0.H 2 S: Load the value stored at memory address2into the multiplier register, preparing it for a multiplication operation.
The final S is not an instruction; it indicates that the operand uses the short format. Short operands were 17 bits, while long operands were 35 bits[6].
As you can see, raw binary instructions are difficult for people to understand and remember. Assembly language therefore represents low-level operations with mnemonics. Converting assembly language into machine code is called assembling.
When no assembler was available, programmers sometimes translated assembly code into machine code themselves. This was called hand assembly. They looked up the numeric code for each mnemonic in an instruction table, calculated the required memory addresses, and constructed the complete machine instructions. Early forms of assembly language were already in use by the late 1940s and early 1950s, before high-level languages became common.
"I'm writing code."
Terminals and time-sharing systems
Interactive terminals with keyboards and displays remained uncommon in the early 1960s. Interactive computing did not begin with Multics, however: MIT's CTSS was first demonstrated in 1961. Early terminals often printed their output on paper rather than displaying it on a screen.
Multics, whose design began in 1964-65 as a joint project of MIT Project MAC, Bell Labs, and General Electric, was intended to advance this approach to time-sharing. Time-sharing divided one computer's processing time into short intervals for multiple users, allowing each person to work interactively at a terminal[3].
"At last, a keyboard and a monitor."
By the 1970s, screen-and-keyboard terminals had become more common. But how did programmers write code and check the results when they did not have direct access to a terminal?
Punched cards and batch processing
Early programmers often used punched cards to write code. Since the late nineteenth century, punched cards had been used to record and store data for machine processing, including work for the U.S. Census Bureau. The basic idea is loosely comparable to a modern OMR (optical mark recognition) sheet: information is encoded by marking, or in this case punching, specific positions.
IBM standardized its widely adopted 80-column card in 1928 and supplied cards, keypunches, readers, and tabulating equipment around the world. Punched cards later became an important medium for entering programs and data into computers[5].
Programmers often first wrote source code on coding sheets and checked it by hand. They or a keypunch operator then punched the program onto cards, usually with one source line per card; a long statement could continue across several cards. A keypunch recorded typed characters as holes in cards. Depending on the language and computer, an assembler or compiler running on the computer, not the keypunch, translated the submitted program into machine code.
"I'd better get this code onto punched cards."
Programmers submitted their card decks to a computer-room operator, who loaded each job into a card reader. They often waited in line to submit a deck and might not receive the printed results until much later. If the program failed, they had to correct or replace the affected cards and submit the deck again.
"Could you check this, please?"
"Next."
Before a program was punched onto cards, copying it could be as simple as transcribing someone else's handwritten source code.
